haha, we both created routing services at identical times... let the battle commence! #185

Let's review eachother's code and discuss design :)

Edit: from a quick review it looks like your Service is much more "batteries included" and mine is much more "sparse simplicity". This is good! We should determine what is actually useful.

I also notice you included History fiddling, which I feel doesn't belong in a Service (but I can absolutely be wrong). I opened #186 to discuss. I'll look more at your code to see if I missed something.

@vitiral @hgzimmerman It's amazing thing! There was no one router and there are two now 😲

Thank you, friends! 👍 Let's try to join the best of two ideas. I could review the both on this weekends.

For all of the original points of concern I brought up, I think I've gotten to a point where I'm comfortable with them. If something isn't inherently clear, it can be addressed in a guide of sorts (eg, best practices for using routing with the fetch service).

What I'm still struggling with is the interface presented to the users of Yew. Currently I have the crate user implement From<&'a RouteInfo> for user_defined::Route and Into<RouteInfo> for user_defined::Route in order for them to easily interface with the router service. This allows crate users to manually determine exactly how route path segments should correspond to the enums that they attach to Props for their components.

This allows flexibility in the case of dynamic paths. For example if instead of the forums::Route being defined as:

pub enum Route {
    CatForum,
    DogForum,
    ForumsList
}

instead it was:

pub enum Route {
    Forum(String),
    ForumsList
}

The crate user can choose to map a path to the forum like so:

match path_segment {
    "cat" => return Route::Forum("cat".to_string()),
    "dog" => return Route::Forum("dog".to_string()),
    _ => return Route::ForumsList
}

or even more dynamically:

if path_segment == "" {
    return Route::ForumsList;
} else {
    return Route::Forum(path_segment.to_string());
}

The problem I have with this current approach is that it is a lot of work for the user to perform per routable component, and I think it can be made to be even less.

@deniskolodin I would like your thoughts about the following proposal. Is this a direction worth moving in?

Using a proc_macro, it should be possible to define attributes that allow an Enum to convert to and from a a path string.
Something like:

// === Forums.rs ===
#[derive(Routable)]
pub enum Route {
    // Instructs the current segment to be stored in the String, as well as to resolve the forum::Route from further path segments
    #[route(path = String)] 
    Forum(String, forum::Route),
    #[route(path = "")]
    ForumsList,
}

By deriving Routable, it would specify that all enum variants require an attribute marking them so that it knows how convert them to and from path strings.
The #[route(path = String)] could convert to the path string to the wrapped type, of course, after trying to match the ones tagged with #[route(path = "something_else")].

In the case where you have a routing component that handles page not found errors it could look like:

// === Main.rs ===
#[derive(Routable)]
enum Route {
    #[route(path = "forums")]
    Forums(forums::Route),
    #[route(path = "login")]
    Login,
    // It will only route to this path if an error is encountered, but will set the url to "pagenotfound" if it does
    #[route(error, path = "pagenotfound")]
    PageNotFoundRoute
}

If any route at any level of routing couldn't be resolved, an error could be propogated upwards through the path-resolving hierarchy until it encounters an enum variant that is tagged with #[route(error)] and the path will resolve to that.

Enums that derived Routable would have TryFrom<&'a RouteInfo> and Into<RouteInfo> implemented for them.

The concerns about this approach are that proc_macros require nightly for now and that excessive use of macros may bloat compile time.
Also, I'm not exactly sure if rust's macro system allows for this aforementioned example work:

    #[route(path = String)] 
    Forum(String, forum::Route),

On the other hand, this doesn't require significant changes to my current design, this merely acts as sugar on top of the existing proposal.

@hgzimmerman Thank you for this PR. It's inspiring.

Routing is a hard to implement feature. Yew looks like React and Elm, but actually has other architecture/implementation, because I couldn't transfer usual approaches to Rust and had forced to reinvent it.

I think we should move the same way with a routing. We should reinvent it again. Sounds strange, but I'll try to dream up: we could use traits to make components Routable and derive routing paths and behaviour automatically. I think it's a good challenge for a language like Rust. You do a good experiments and we should move them forward to the desired state.

@deniskolodin interesting... components as the primary endpoint of routes...

I think this missses that there can be a lot of information within the route. I feel that a Msg is the correct result of a route, correct? For instance, someone might have a specific query or hash -- handled by a component (maybe...) but has more info.

Or are you thinking of doing a component+msg... or something?

I feel like adding complexity here is a mistake. Fortunately it has been proven that a "simple" router can easily be an external crate -- so by all means we can try multiple solutions (including one supported in core). Regardless I think it's a good idea to try out a lot of soutions. Please include me on the review!

Thanks Denis.

I've been dogfooding my ~2.5kloc Yew-based project with the routing implementation in this PR and I have a few observations:

• It works very well with static routes.
• As soon as I throw a dynamic route at it, a mismatch between routing and data appears. The obvious by default pattern is to have the parent resolve the route of the child and then instantiate the child component via the view. This doesn't have great ergonomics when you need to set the path based on the state of the child of the component responsible for setting the path.
• Using this solution is still very verbose, as using the router requires specifying both "from route" and "to route" functions that usually contain the same data, just moving in "opposite directions".

I think that for any robust routing system, the mechanism that performs routing needs to operate on a tree (either defined at compile time, or dynamically). Defining how that tree is constructed and the rules for its resolution from a string are the responsibility of the router authors.

With your suggestion that we attempt to reinvent routing, binding the routing logic to the component/model, the following is the best proposal I could come up with in a short period of time.

First, I suggest we move away from defining routing enums that dictate which child component gets rendered by the routing component.
Instead, any component that can be routed to defines the conditions on which it will be routed to (route_to), and what its route will be(to_route). These can be different for catch-all cases like "PageNotFound" pages, but for static routes, the path section string should always be the same, and hence those two functions could be covered by a proc_macro_derive.
Then, that component's parent could register with the router service what children it could possibly route to. When routing, the router would iterate through the path_segments vector, and for each segment it would try to resolve which child it could instantiate based on the child's "route_to" function.
In the render function of the parent, some syntax could be added to allow Yew to insert the child at that location.

This would allow Yew to dynamically create a decision tree where each node in the tree can decide for itself if it gets rendered or if its parent node moves on to try to match against the next possible component.

In all, some of the magic bits would have to be ironed out, but I think it could look roughly like;

struct ParentModel {
    ...
}

impl Component<Context> for ParentModel {
    fn create(props: Self::Properties, context: &mut Env<Context, Self>) -> Self {
        // Some macro magic may be required for this to work
        context.routing.register_routes(vec![ChildModel::from_route, PageNotFoundModel::from_route]); // Ordering is significant
        ...
    }
    ...
}

impl Renderable<Context, ParentModel> for ParentModel {
    fn view(&self) -> Html<Context, Self> {
        html!{
            <YEW_ROUTER></YEW_ROUTER> // Yew would insert the resolved child here
        }
    }
}


////////////////////////////

#[derive(Routable)]
#[path = "child"] // Will only match if the path segment == "child"
pub struct ChildModel {
    ...
}

impl Component<Context> for ChildModel {
    ...
}

impl Renderable<Context, ChildModel> for ChildModel {
    ...
}


//////////////////////////////

pub struct Props {}

pub struct PageNotFoundModel {
    ...
}

impl Component<Context> for PageNotFoundModel {
    ...
}

impl Renderable<Context, PageNotFoundModel> for PageNotFoundModel {
    ...
}

impl Routable for PageNotFoundModel {
    // The Option return type would indicate if the route matched or not.
    // If it did match, then the props are passed to the create function
    fn from_route(_route: RouteInfo) -> Option<Props> {
        Ok(Props {})
    }
    fn to_route(&self) -> RouteInfo {
        route_info!("/PageNotFound")
    }
}

With this approach, I am worried about the possibility of re-creating the whole hierarchy of routable components when any part of the route changes. I don't know much about Yew's internals, but maybe in the section of code that resolves the route, it could check if the component corresponding to the props returned from from_route exists or not and depending on that, either destruct the prior component and instantiate the new one or just pass the props to the existing component's change() method.

This also has the problem of tightly coupling the router to Yew via the proposed specific routing "html!" syntax, making extracting it to another crate next to impossible.

I've been thinking about the proposed alternative from above for a few days and I think I came up with something better.

To avoid some of the magic and tight coupling, as well as removing some ambiguity on how the accidental recreation problem can be avoided, I propose the following.

The Routable traits will look approximately like

/// The component that implements this trait shouldn't correspond to any route itself,
/// but does have children that the router will need to resolve. 
/// When the router determines which child to route to, set_child() will be called and
/// will update the child field of the Model. This should be easily deriveable in most cases.
/// There should only be one Model that implements this trait, as it will be the start of where routing occurs.
trait RoutableRoot {
    fn set_child<T>(&mut self, T) 
        where T: RoutableChild + Component<??> + Renderable<??>;
}

/// This trait should be implemented or derived for Models that sit below the RoutableRoot,
/// but have children themselves.
trait RoutableNode {
    // RoutePath is just an alias to string
    fn from_route(route: RoutePath) -> Option<Props>;
    fn to_route(&self) -> RoutePath;
    fn set_child<T>(&mut self, T) 
        where T: Component<??> + Renderable<??>;
}

/// The router will want to be able to resolve the component that implements this, 
/// but because it doesn't have any children, there doesn't need to be any set_child function.
trait RoutableLeaf {
    // RouteLeaf is a struct that contains the last segment from a vec of path segments,
    // as well as options of both fragment and query.
    fn from_route(route: RouteLeaf) -> Option<Props>;
    fn to_route(&self) -> RouteLeaf;
}

The router service would break down the existing RouteInfo structs into component RoutePaths and RouteLeafs via iteration and attempt to resolve different Routable components based on them.

The ChildModel would remain similar to implementation shown in my prior comment. For the ParentModel, it would now look like:

#[derive(RoutableRoot)]
struct<T> ParentModel 
    where T: RoutableChild // Marker trait applied to both RoutableNode and RoutableLeaf (?)
        + Component<??>
        + Renderable<??>
{
    #[child]
    child: T
}

impl Component<Context> for ParentModel {
    fn create(props: Self::Properties, context: &mut Env<Context, Self>) -> Self {
        // Some macro magic may be required for this to work
        let routes = magic_macro!(ChildModel, PageNotFoundModel]); // Ordering is significant

        // This now takes a reference to &mut self that it uses to create a callback that will 
        // execute set_child() when it determines a child route.
        context.routing.register_routes(routes); 
        ...
    }
    ...
}

impl Renderable<Context, ParentModel> for ParentModel {
    fn view(&self) -> Html<Context, Self> {
        html!{
            {self.child.view()}
        }
    }
}

The router service, using information from magic_macro!, could generate one of many possible Props structs from the route info and instantiate the child component that corresponds to it. Then pass this component to the callback and call set_child() with it. (this can't be done with the current design because the register_routes() function as designed can't take a &mut reference to a self that doesn't exist yet, but I think this can be designed around using Tasks)

No idea if this is possible to implement (hence the ??s in the type signatures for Component and Renderable), but I think its a novel approach worth exploring.

@deniskolodin I would like some reassurance that this is the direction we would like to move routing with Yew towards before I start attempting to implement a routing backend that supports this sort of interface to the crate user.

EDIT:
In order to avoid the awkwardness with the proposed Marker trait, I could condense the traits into:

trait Router {
    fn set_child<T>(&mut self, T) 
        where T: Routable + Component<??> + Renderable<??>;
}

trait RoutableNode : Routable + Router; // Is this distinct trait even necessary anymore?

trait Routable {
    fn from_route(route: RouteLeaf) -> Option<Props>;
    fn to_route(&self) -> RouteLeaf;
}

@hgzimmerman Thank you for these experiments. The last concept come closer to a perfect solution.
I expect the routing should be a utility which you don't need to think about for joining.

For example:

// Somewhere in the framework
trait Routable {
    fn get_part(&self) -> String;
    fn tune_from_part(&mut self, path: &str) -> Result<(), Its404>;
}

impl<CTX, COMP> Scope<CTX, COMP> {
    pub fn mount_in_place(...) {
        self.fit_to_url_path(); // Impl depends on `COMP: Renderable`
    }
}

struct Its404; // Error
type UrlPart = String;

// In the app
enum Model {
    Scene1,
    Scene2,
}

trait Routable {
    fn get_part(&self) -> UrlPart {
        let part = match *self {
            Model::Scene1 => "scene1",
            Model::Scene2 => "scene2",
        };
        part.to_owned()
    }
    fn tune_from_part(&mut self, path: &str) -> Result<(), Its404> {
        match path {
            "scene1" => {
                *self = Model::Scene1;
                Ok(())
            },
            "scene1" => {
                *self = Model::Scene1;
                Ok(())
            },
            _ => {
                Err(Its404)
            },
        };
    }
}

Child components also have to play this rules.
Let's imagine the case when you could use even a complex regex to restore a state. I think it should be great.
... error handling still is a slimy question )

I did try to implement my 2nd/3rd suggestion but did run into problems regarding creating new components and trying to infer what a component is depending based on the props. That was a bad idea.

Provided the self.fit_to_url_path() hooks into yew's render cycle at the right point, then I see that suggestion as far superior to users having to define a set_child().

I do have some concerns about how this would work to users of Yew.

I think the component itself needs to be aware of the changes the router performs.
If a component makes a network request based on what the route is. eg: /users/34, you would want to expose the ability to make a request when the router detects the change.

This would involve 3 components, the main component, the users component (which could also just show a list of users), and the individual user viewer component. So the router would want to create sets of enums like: Model::User, UserModel::Individual(34) from the route string. Whenever the user id changes, you would want to cause the viewer component to request new user data to show from the server.

So directly mutating the component shouldn't be an option. Instead, you either want to allow the context in tune_from_part() so you can register callbackts to the fetch service or you return the child component's Properties from tune_from_part(), and mount_in_place adds the props to the updates vector. Then the user can do their networking in the change() method. This would require the Routable trait to look like:

trait Routable: Component<...> { // you can only implement Routable for things that already implement Component
    fn get_part(&self) -> String;
    fn tune_from_part(&mut self, path: &str) -> Result<Self::Properties, Its404>;
}

This creates additional questions. How do we determine if the route really did change for this component, and not some child component in the case of users/34/#settings? You wouldn't want to make network requests if you didn't have to.
Conceptually, if we retain the structured RouteInfo object, Yew, or possibly the user, could perform an equality check against get_part() and the new route segment, and if they are the same, allow the user to branch to avoid making network requests.

In regards to error handling, perhaps a default method could be added to Routable to handle route errors. By default, it does nothing, maybe it logs an error to the console. But users can override that to set the scene/child for a component if they want. Then if it is possible, a mechanism could be developed to bubble the error up to parent components until one is encountered that does override the handle_route_error method.

Now that I look at it, I think that there a a few ambiguities that I would like to clear up regarding what you want out of a routing service.

I'm inclined to keep throwing ideas at the wall about how routing could be done, starting with how we think what interfaces should be presented to users, and working backwards from there to see if it is possible to implement. Once we settle on a design, I'll try implementing another prototype.

• Do you want there to be a single point of routing? Should there be one top-level component that gets the full route info, or full route String, and uses that to create a nested enum that contains the information for all of the children it has?
• Or do you want there to be multiple components that are responsible for routing? Each component is responsible for determining what its child is, and can hook into Yew and the router to get routing information that is relevant to it.
  • If this is the choice, does the whole RouteInfo get passed to the component? If that is the case, then deriving static routes would be more difficult, as the path section index that each component corresponds to would have to be specified by the crate user.
• Do you want to use unstructured strings to represent the path, query, and fragment, or are you in favor of the RouteInfo approach.
  • If you want to use the RouteInfo, are you in favor of further segmenting it and presenting only sections of it at a time to users, or should they have access to the whole thing, and have them be responsible for determining what section(s) they want to route with?
• You mentioned that you want to eventually decouple Yew from its services, to move them into separate crates. By hooking into mount_in_place(), you tightly couple the router to Yew, which would make it harder to separate them in the future. Do you have a solution for this? Possibly expose some way for services to hook into the component lifecycle in a generic way?

Going in an entirely different direction...

• I've looked at some of Yew's internals and I sort of see how you could deal with a Routable, but for the most part, it seems to beyond me, so I apologize in advance for any impossibilities I suggest here. It does give me the idea that if we are going to tightly couple the router to Yew, one avenue of doing so could be creating something like a VRoute struct, similar to VComp, that is dictated by a user implementing Routable or Router (whatever we decide to call it) on a struct. This node variant would be responsible for resolving a child VComp depending on the user's implementation of tune_from_part(). Even though my current prototype implements routing on top of a Component, I think it would be simpler from a user's experience to have routers and components be distinct from each other. So for a component, they could have a Model tied to displaying things and managing user input, and then a Router that they specify in the component's view like:

html!{
    <div>
        <div> Normal component things</div>
        <Router: />
    </div>
}

And all the `<Router: /> does is choose what the nested component would be. Because the state of a Component and what its routed child is should be orthogonal, I think they should be separated if possible.

I have several concerns about this approach. From the way I see it, a user of this approach is required to:

• create a Route enum
• implement trait Router with two methods for Route
• implement Renderable for Route.

This is a lot of boilerplate which does not fit into the rest of the ecosystem (rendering IMO should only happen from the Model::view but this will somehow circumvent that?). Even worse, it has no way of converting a route into a Msg -- so you can not do more complex things like handle query strings, etc. I'm also confused how history State changes could be handled when you have no way of transmitting data via a Msg.

The approach I outlined uses a single function to accomplish the routing task and can handle all of the above concerns. If the user wants additional security they can use enums and macros to validate that their endpoints are valid html as much as they would like.

I think the router should stay out of the user's way and give them maximum flexibility. This solution gives very little flexibility requires them to use the router for only rendering a view.

I will make the argument that in order to easily resolve which page or page hierarchy to display when a user enters the site with a route already specified in the URL, the routing framework requires that the developer specify ways for a page to both set the route, as well as determine how to render itself by using the route. If that can be accomplished in a single function, I will be impressed, but as far as I can tell, your proposed solution does not facilitate the setting of the route via Yew. Your example uses <a> tags to set the fragment, which doesn't reload the page, and for that application, it works fine. But if you want to set the path using <a> tags, that will trigger a page reload (please correct me if I'm wrong about this point), which isn't desirable in a SPA. Therefore, there needs to be some framework-based means of setting the route without triggering page reloads.

I acknowledge that my approach brings about significant baggage in the form of boilerplate, but in order to address the requirements of both setting and "serializing" state via a route string, I think it is necessary and justified.

To address your other concerns:

• Creating a Msg isn't strictly necessary, my approach sets application state by determining which child component to render via an enum variant resolved from the route, and propagates changes via the change() method instead of update() as you seem to suggest.
• It is also possible to set up a monolithic Router at the top of your application that will set each layer of child components beneath it. It isn't strictly necessary to implement Router for every route level in your component hierarchy, although I do believe that it is a good code organization practice and encourage it in my example.
  • That monolithic router is capable of dealing with strings, as the provided RouteInfo has a to_string() method. This would allow the use of regexes or nested pattern matching on the route string to set the route enum.
• If you would like to see the router used in a more real context, I'm currently using it in an unfinished medium sized project. It serves my needs well (although it definitely could be better), and demonstrates some flexibility that my example doesn't, like working with dynamic routes. The code is available here: https://github.com/hgzimmerman/WeekendAtJoes4/tree/master/frontend7/src . I suggest just reading it instead of running it because it relies on a backend server, and setting that up may be painful.

I will have more complete thoughts about it later, but I would like to admit that I think I was wrong to prefer that the set_route() method only take a T: Router, and that a String would be a better, more flexible parameter.

For the current implementation, I think that the Router trait is a good idea, but I don't think its use should be required by Yew itself.

I've used this router to build what is currently a 5kloc app, and will continue to make changes to this branch to iron-out edge cases. Feedback and discussion are still appreciated.

I'm going to dive back into this in the coming days. I haven't played around with Yew 0.6 features (actor update) yet, but I think the recent changes map very well to what I want to accomplish with routing.

• I think the routing service should be simple, dealing with strings as its inputs and outputs. This will ship as another one of Yew's services.

• A more strictly defined system would be implemented as part of a Worker that components that care about routing could link to. This Worker would appear only in the example code and wouldn't ship with the library itself.

  • This way, the library endorses what I hope to be a reasonable full routing solution, but the primitive routing system is kept simple and flexible so that people can arrive at better or more relevant solutions over time without involving breaking changes to the library API.

• The current routing prototype involves getting a string from the location service, parsing it into an intermediate representation of path, query, and fragment strings and then letting a series of developer-defied enums try to create variants of themselves from these strings in a hierarchical fashion, mutably consuming path strings along the way, and only exposing the query and fragment strings to the last element. This obviously has problems; like what if the component that deals with the bar sub-path in url: .../foo/bar/baz?index=3 is responsible for pagination using the index query string?

• The newer routing system will involve any component interested in routing linking to a Router (Worker?) actor. This involves setting a callback in create() that will receive messages from the Router and forward them to the component's update() function so that the developer can determine how to route itself. The component will also have to pull path, query and fragment information from the Router in create() as well. Because this information will be available all the time, this should remove the necessity of mutation of RouteInfo and allows any part of the route to be accessed by a routed component. This has the drawback of causing the "routing schema" to be more loosely defined, but I think that could be mitigated if one so chooses.

Hopefully, I'll have something like this ready in a couple of days.

Since was #296 merged, this can be closed now.